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(57) Abstract: Communication between a private 
network (1) and a roamning mobile terminal (4), 
the private network (1) including a home agent 
(5) for the mobile terminal and a gateway (2, 
3) through which, the communicationpassesand 
which -provides security protection for the private 
network (l).The protocolsof thecommunication 
Including security association bundles each 
include a security association between the mobile 
terminal (4) and the gateway (2, 3) for inbound 
communication and another security association 
for outbound communication. In response to a 
handover of communication causing an IP address. 
(MN Co @) of the mobile terminal (4), to change 
to a new IP address (MN: New Co @), the mobile 
terminal updates its inbound security association 
from the, gateway (2, 3) so that it can receive 
packets sent to it with the new IP address (MN 
New Co @) as destination. It sends a first signalling 
message with: the home agent (5) as destination: in 
a secure tunnel (20*) to the gateway (2, 3), indicating 
the new IP address (MN,New Co @) in secure 
form to the home agent (5). The inbound security association of the gateway (2, 3 ) from the mobile terminal (4) accets the first 
signalling message without cheking its source address. The gatewa (2, 3) forwards the first signalling message within the private 
network (1) to the home agent (5), the home agent (5) checks the validity of the first signalling message and, if It is valid, updates 
its address data and sends a second signalling message to the gateway (2,3) indicating the new address (MN New Co @). The 
gateway (2, 3) updates its outbound security association with the mobile terminal (4) in response to the new address (MN New Co 
@) indicated. Preferably, communication between the mobile node (4) and the gateway (2, 3) is in accordance with IPsec and an 
Encapsulating Security Paypepad protocol used in tunnel mode. Peferably, a registration reply for the mobile node (4) is included 
In the second signalling message 
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Title :. Communication between a private network; and a roaming - mobile 
terminal « ! - : > .• - 



. Description -■ 

\. 5 Field of the invention 

v=- This invention relates; to, communication: between a; private network and a 
^ ;^ iroarnirig mobile terminal. * ! •; ."■ 

Background of the invention " ' ' - /v-;: ^ :v 

'' ; V - Many organisations utilise private networks, whose communications; with 
10 terminals outside the private network pass through security gateways that protect 
the private network using techniques including firewalls. 

Protection of private corporate information is of utmost importance when 
designing an information infrastructure. However, the separate private networking 
solutions are expensive and cannot be updated quickly to adapt to changes In 

15 ; business requirements. The Internet, on the other hand, js inexpensive but does ; :^ 
not by itself ensure privacy. Virtual private networking id the collection of 
technologies applied to a public network - in particular the Internet - to provide 
solutions for private networking needs. Virtual private networks use obfuscation 
through secure tunnels, rather than physical separation, to keep communications 

20 *. private. ] ]• , " ; ; - : !■ _ ■ ■ .■ " ;■ 

Virtual private networks. (VPN') accordingly enable private networks to be 
extended to enable securltised communication with roarriirig terminals, that, is to 
say terminals situated outside the private network, the communication passing for 
example through the Internet and possibly over mobile telephone networks^ Trie 
25 Internet uses Internet Protocol ('IP') and trie communications of mobile terminals 
^ often use Mobile lnternet,Protocol ( r MlP'). 

, it is expected that the roaming usage of virtual private networks will become . 
" bigger and more frequent. Such frequently roaming users will need;to be given the,, 
same level of security as; fixed or occasional roaming terminals, through the^ 
30 , corporate. VPN / firewall architecture. . "■. 



Different communication arid security protocols are used for the different 
networks. An example of . Internet security protocol is the. IPsec specification [S. 
Kent, R. Atkinson , "Security Architecture for . the Internet Protocol", . Internet 
Engineering Task Force (IETF)! RFC 2401, November 1998]! Examples of mobile 
telephone coriimunication protocols are the Mobile IPv4 specification [C; Perkins, 
"IP. Mobility Support", RFC 2002, October 1996] and the Mobile IPv6 specification: 
When the VPN protocol is; IPsec Encapsulating Security Payload and the mobilry. 
protocol is Mobile IP, both of them being implemented in the saVne-iP- layer, there 
is a heed to specify how these two protocols must interact with each other when 
being simultaneously required. 

Beyond basic application order- (either apply Mobile IP first, or apply IPsec 
first), the overall solution must aim at meeting three major requirements: V 
© Security. The fact that VPN infrastructure can support Mobile-IP users must 
not create new security flaws to any corporate entity (corporate network & 
mobile or occasionally roaming users). Mobile IP enabled devices must 
provide mobile users with the same level of security as if they were 
physically located within the corporate network. On the other hand, Mobile 
IP entities must be adequately protected by corporate security infrastructure 
(Firewalls) and Mobile IP specific security mechanism must not interfere 
with global security mechanism, 
o Compatibility. A solution that enables optimised interaction between Mobile 
IP and IPsec must avoid heavily modifying protocol specifications. Future 
evolutions of Mobile IP & IPsec protocols must not be made excessively 
difficult due to the use of an optimised combined solution. Optimally, such 
evolutions should be transparent to the use of the combined solution. 
• Performance. The invention must address specific needs of mobile users in 
terms of handover quality: the handover must be made as quick as 
possible. : 

One example of a communication protocol for a virtual private network is the 
ESP s (Encapsulating Security Payload) protocol (S, Kent, R. Atkinson, "IP 
Encapsulating Security Payload", Internet Engineering Task Force (IETF), RFC 
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•■ 2406, November 1 998), used in tunnel mode the most significant points are the : 
L following' >* ' '• . \ - _ ';• ' ; i . \ , 

• -The whole incoming IP packet is tunnelled into a new one, inner {original) 
' source and destination addresses are hot changed 

. , : 5\ !;\ ' u \?' : The^whpte incoming! IP packet is i encrypted arid optionally (recommended) ; ". 
• •"" ' authenticated • --'v.- >■-• & 

!! r ! ESP!! tunnel mode ! is by . definition a unidirectional peer-to-peer protocol; The \' : ; 
J : sender; (the one; that , encrypts and tunnels) and ' the receiver (the r one that ; ; 

detunnels and dec^pts) must share a cryptographic secret (e.g. Key and algorithm' \ ; 
10' . used for encryption/decryption).. The set of security parameters (protocol, key,!; \. 
:!vv'"' /''!algorithrn r: se.nde"r: t adclress,' receiver address,! lifetimes ..,) .constitutes 3 so-called 
IPsec Security Association ( £ SA*j. IPsec requires two SAs (an SA bundle) to obtain 
a secured unidirectional communication: one on the sender and one on the , 
receiver (with some common parameters, for example the key). 

15 : As a VPN communication is bidirectional (from Mobile Node ('MN') to VPN 
Gateway and from VPN Gateway to MN), two SA bundles are required: the first 
- dhe describes the tunnel from MN.,t^ 
tunnel from. VPN Gateway to Mfsl- Jt must be noted that the designation 'VPN 
Gateway" is hot specified by the protocol: a VPN Gateway is simply the topblogic 

20 entity, that terminates, at the corporate network side, all VPN secure tunnels, 
to/from roaming mobile nodes. - 

SA selectors are used for the processing of IPsec packets. Basically, SA 
selectors are IP parameters that are used by IPsec layer to check that: !'! 

• A packet that is about to be. sent on a tunnel defined by a certain outbound/ : 
25 SA is actually legitimate to be sent with that SA (e.g. source & destination 

, addresses of the packet match with source and destination address of the . 
. . SA). This test is called the "outbound SA selector check". ' . v 

• A packet that has been received from a tunnel defined; by a certain inbound 
SA is actually legitimate to have- been received with this SA {e.g. source & 

\ 30. : , destination addresses . of trie packet match - with : sourcef arid destination 
L address of the SA); This test is called the "inbound SA selector check": > 
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It must be noted that, as Illustrated in the two examples.above, only source 
\ address. & destination address will be considered in this invention as SA selectors? 
4 for both inbound andoutboundSAs. ^ ' ■ •> ;- ! -; 

Two- families of proposals address this situation;' "*••'-.' - - - 

5 / JPsec tunnel in the MIP tunnel. 

With this family of proposals/ the iPsec tunnel is established between the \-. 
VPN Gateway and the Mobile Node Home. Address. . \' : ./ ; r ■'" 

\ External home agent . The home agent is placed in front of the IPsec gateway 
... and the corporate firewall, i.e. outside the home network. „ Obviously, there are 
" 1 0 deep security flaws; the main one is that the home agent is no longer protected by ; 
. the common protection (corporate firewall) mechanism at the border of the 
network. Indeed, a home agent placed outside the gateway does not benefit from 
any protection and become an easy target. This kind of security flaw could not be 
accepted when designing a VPN solution aimed at securing communications. 

15 Another problem stems from the tunnelling mechanism that does not cipher 

the MlP.packets (the IPsec tunnel is inside the MIP. tunnel). The, MIP header is in 
plain text and any attacker with bad intentions will have knowledge of all header 
fields, for instance the home address of the mobile node. Thus, this solution does 
not provide privacy and a malicious node might track all successive locations of a 

20 mobile node, identified through its home address. 

MIP proxy . This proposal is described in a draft (F. Adrangi, R. Iyer, "Mobile 
IPv4 Traversal across VPN or NAT & VPN Gateway", IETF work in progress draft- 
adrangi-mobileip-natvpnrtraversial-Ol.bct, February 2002). It assumes the creation 
of a new entity called a Mobile IP Proxy that appears as a surrogate home agent 
25 from a mobile node point of view and conversely is viewed as a mobile node by 
the home agent. This solution is also based on IPsec in MIP tunnelling, which is 
less confidential in terms of privacy than MIP in IPsec as stated above: 

The process of simple roaming requires hew signalling messages \ 
. the MIP proxy, the VPN gateway, and the home agent: the MIP proxy acts as a 
30 relay between the mobile node and the home agent ('HA'); it must be, aware of 
existing protection between the mobile node and the HA to forward valid request 
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- 5 - 



uniquely. It also interacts with the VPN gateway and a common packet from a 
; cprrespondent node to ;a; MN folio ws a : heavy process:; it is first M IP-encapsulated" 
by the HA to the M IP proxy Then the MIP proxy decapsulates (tend gives it to the. 
VPN gateway in order to realize encryption The VPN gateway sends back the 
5 ciphered packets to the MIP proxy : which encapsulates it again in a new MIP 
packet % "■ - •. " " 

The MIP proxy is located outsrde the protected domain in the Demilitarized 
; ; Zone ( c DMZ') t that is to say a small network inserted as; a, "neutral zone" between 
a company's private network and the outside public network. The security level of r 
10 machines within the DMZ is; far inferior ^ to corporate network. The firewalls, 
must not interfere with the registraUori prdceclure'beihveer) the proxy and the Home ] 
Agent. This architecture implies possible security flaws since the corporate firewall 
must let any packets between the MIP proxy , and the Home Agent go through 
without further inspections: this can easily lead to compromise the entire corporate 
15 . network if ah attacker can manage to gain access to the MIP proxy. 

flff/F tunnel in the IP&ec tunnel 

J v; ■ / ; With • 'this; family of proposals, an IPsec tunnel is established between the ! 
• . VPN' Gateway and the Mobile. Node Gafe<>f Address. V ; , 

One proposal that includes the MIP tunnel in the IPsec tunnel has been 
20 described by the University of Bern. • Switzerland . at 
\yww.iam.unibe.ch/--rvs/publications/secniip_gi.pdf. The IPsec tunnel is reset 
before any new handover. When moving to a new. network, it has to be re- 
. established through the whole key distribution process. That handover mode 
creates unacceptable latencies of many seconds, incompatible with classical MIP 
25 requirements. . 

: Another issue with this proposal consists in assuming that IPsec offers a 
y sufficient protection and, as a consequence, in disabling authentication and replay ... 
protections during the MIP registration procedure. Disabling protections on the , 
Home; Agent is ah option that does not really improve speed and requires home. 
30 • agents dedicated to MIPrVPN users, .as well as other" home a^nts\ dedicated, to.-' 
; slmpIeiMIP users that still use Ml P. protections . . '/ " " \\\ . 
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! 1 ')::• ■: T ne Present invention addresses: the above and other problems.'; )}"\ ; ; - 

7 ; Summary of the invention *. . * ' " ■" ! : [ 

The present; invention ';; provides . a method . of and • ^apparatus for 
: ~; communication as described in the accompanying; claims. : v - : % ■ • 

.. - 5 * : ; Brief description of the drawings V .\v' ^ r '['■ ' * • T ■- 

FigureM is a schematic diagram of a mobile virtual private network scenario. . ; 

: Figure 2 is a diagram of a_data packet encapsulated in ESP tunnel mode. 

Figure 3 is a flow chart of exchanges in communication: between a private • 
network and a roaming mobile terminal in accordance with one embodiment of the 
10 invention, given by way of example, and 

Figure 4 is a flow chart of a process for reception of a registration request in 
the communication process illustrated in Figure 3. 

Detailed description of the preferred embodiments 

Figure 1 shows a mobile virtual private network scenario comprising a private 
15 network 1 including a security gateway ^ comprising a VPN; gateway 2 and a firewall 
3, a mobile node 4 situated in the private network 1 and a home agent 5 for the 
mobile node 4. The embodiment of the present invention shown in the drawings is 
applicable especially where the mobile node 4 is capable of communication over a 
wireless link, which improves its ability to roam, both within and outside the private 
20 network 1 but this embodiment of the invention is also applicable where the mobile 
node 4 communicates only over wire connections. 

Figure 1 shows a scenario where the advaniages of this embodiment of the : 
invention are particularly appreciable, where the mobile node 4 moves outside the 
private network 1, first to a visited network 6 having a foreign agent 7 functioning 
25 t ' under mobile IPV4 protocol, enabling communication of the roaming mobile node 
4 in the network 6 through the internet 8 with the private network 1 . In this scenario 
the roaming mobile node 4 then moves to a second visited network 9, having a 
foreign agent 1 0, also functioning under mobile IPV4 for communication through 
the internet 8 with the private network 1 While this embodiment of the invention . 
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: '.\«iA " •Wnjfloh? Wfjth Mobile; IPv4 protocp!s,;U will be invention is also., 

■ >.; ; "; 'applicable to -other protocols; especially the Mobile IPv6 protocol. : \ • y % ! : " \ \ LK; *>.•-, 

; >; . : 1 ; When ; the :rriobiie, ; node _! 4 is roaming in the visited ; h^tworks : 6 or ■ 9, « 
\'\-\\ communications with the private. network 1 are established through the internet 8 '-: 
1:5. In IPsec and. MIP: tunnels .14 ahct 12 respectively. More specifically^ the protocol. 
; • : ! ;Msed; is the encapsulating security; payload -("ESP") ; protocol illustrated' in Figure 21 • : " 
• l : 'According 'to this, protocol, ■ the 'original packet 13 comprises an original JP header ; 
14 and data^ ;15. The packed 13; is encrypted with an i:ESP trailer 16 without 
: . changing the original IP header and destination address. The encrypted packet is 
1 I ,™ ! encapsulated with an ESP header 17 and preferably an BSP authentication 18 " 
and assembled .with a new IP header 19 before 'transmission. Security assodalion. 
•bundles, each comprising an outbound arid inbound communication security 
association, are established for communications over the paths 1 1 and 12 with the y r 
VPN gateway 2. Security association selectors check that packets to be sent using 
15 the tunnel defined by each outbound security association are legitimate to be sent 
with that security association and, in particular, that the source and destination 
addresses of the packet match, with the source and destination addresses of the * 
: : ; : \ security association, this ; test being the outbound SA selector check. Jackets .. m 
received from a tunnel defined by the inbound security association are checked for ■ * 
20 legitimacy of reception with this security association and, in particular, that the 
source and destination addresses of the packet match the source and destination 
addresses of the security association, this test, being the inbound SA selector 
check. , 7 • '■ ; -7 ; ' ., - . .'I , "' ' 

fn this embodiment of the invention the inbound security association of the ■ 
25 VPN gateway 2 does not contain the; IP address .of the mobile node 4 as source 
V address but a wild card ("*"). This allows the VPN gateway. 2 to receive and 
; forward a packet from the. mobile node 4 whatever Care-bf address it may use. ft . 

will be noted that this is not contradictory with IPsec protocol, since the wild card 
value is authorised by this protocol for the source address selector in a .security 
30 association. The tunnel order is that of an MlP tunriel in the IPsec tunnel, with the ' 
: ; IPseotunnel between the VPN gateway 2 and the mobile node 4, using the mobile 
node Care^f address as end point , 
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•■ ; , : '' .', - ".'•.■: = '-- -: : /-^-^O- '' '' '■ "■' : " ."• 

The process for communications when the mobile node 4 is roaming is 
shown in Figure 3, in which references to outbound arid {nbound refer to packets. 
: - j at the mobile node 4. = Initially, the I Psec tunnels are, illustrated for the situation : 
: where communication is established at me; current Care-of address of the mobile 
5 : . node 4/ The outbound J Psec tunrie) 20 has/a security association at the mobile 
node 4, having the current mobile node Care-of address as source address and 
: ; : the address of the VPN gateway; 2 as destination address, and a security ; 
association at the VPN gateway 2, having a wild card as the source address and . 
the VPN gateway 2 address as the destination address. The initial inbound IPsec 
10 •;■ ; tunnel has a security association at the mobile node 4, with the address of the 
VPN gateway 2 as source address and the current Care-of address of the mobile 
node 4 as destination address, and a security association at the A/PN gateway 2, 
having the VPN gateway address as source address and the mobile node 4 Care- 
of address as destination address. 

15 When the mobile node moves at 22 from one visited network to another, for 

example, from the visited network 6 tc the visited network 9, the mobile node 4 
recognises that its location has changed, for example, from an incoming agent . 
advertisement. It then configures a new Care-of address that is routable within the . 
new visited network 7 The mobile node 4 contains VPN client software that ." 

20 responds to the change in mobile node location, for example, in response to 
network selection middleware or by monitoring the source addresses of outbound 
packets. The VPN client software then changes dynamically the inbound security 
■ association on the mobile node 4 so that its destination address is the new Care-of 
address of the mobile node, the inbound IPsec tunnel 21 becoming a temporary 
. 25; inbound IPsec tunnel 23. In this way the mobile node 4 will be able to receive . 
packets securely sent by the VPN gateway 2 to its new Care-of address; otherwise 
the packets would be dropped as they would not match the destination address 
included in the former inbound IPsec tunnel 21. Similarly the VPN client software 
changes dynamically the outbound security association on the mobile node 4, so 

30 ; that its source address is. the new Care-of address of the mobile node, the 
outbound IPsec tunnel 20 becoming an outbound IPsec tunnel 20*; otherwise the 
mobile node 4 would not be able to send outgoing packets as they would not . 
match the source address included in the former outbound IPsec tunnel 20. 
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„ -., The mobile node 4 then sends a signalling message to its home agent to 
inform it ofjts new location, the signalling messajge passing through the outbound " 
* v > f |P se fe tunr\e\'2&anp the VPN gateway 2 ; This signalling message is in the form'of 
a registration request where the protocol used is mobile |PV4 fl as in this 

- y^Siv embodiment pf the; invention. ^ - : ; " ;;?V-\! ■^SK^^!' : ^^ ^ ' : •'/ 5 ^*V"!'^i' , * , ' v/-."-- 

*1 The signalling message is received at the VPN gateway 2 in step 24, The SA 
: . ; " : : : ! selector in the VPN gateway for th e outbound turinef 20' does not reject the; packef 
0 Y / Vsince-the source address Is ;'a wild card field and the source address is therefore 

not verified and: the" packet is fon^^ 
-~ : ^A\. -agent 5 receives and [ processes the registration request message from toe mobile 
x . : : r ^ode 4 indicating the new Care-of address. If the registration: request is valid the ; 
home agent 5 sends a security information update message! ("SiO*)- to the VPN 
gateway 2 containing an order to update the security association of the temporary 
IPsec tunnel 23 on the VPN gateway. This SIU message is processed at the VPN ( 
15 gateway 2 by a daemon, for example, that is to say a background programme that 
provides services to the system. 

In response to the SIU message; the VPN gateway 2 updates its security X 
; association for the; temporary inbound IPsec tunnel 23 to a new IPsec tunnel 26/ ; 
having the new Care-of address of the mobile node 4 as destination address. This 
20; update is performed before any packet is sent to the mobile node 4, in particular 
the registration reply. In a preferred embodiment of the invention the SIU message 
from the home agent 5 to the VPN gateway 2 includes the registration reply to the 

- ..•A .: . mobile node 4/. y ! - - ■ \ \ ' J - . • 

• * It will be ■ appreciated that this particular routine of the home agent 1 \s ;. 
, 25 triggered only when the registration request is received through a VPN gateway 
such as 2 f corresponding to a location of : the -mobile node 4 outside the private 
network 1. If the mobile, node were situated within the private network"; 1,' and 
therefore' not using the VPN service, the home agent 5 would respond according 
to the nqrmai routine with a normal registration reply. : : . /, ; 

; .-3_0« V At step 27, the VPN gateway 2 forwards. the registration. reply to the mobile ! ; 
. \node,4 using the newly-established inbound IPsec.tunnel 26 and sends a!l!further ' \ 
data packets to the new Care-pf address using the tunnel 26 untif further notice. 
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.. . If at step 25 the. registration request does not succeed at the home agent 5, 

' . the process is not "irremediably compromised. No registration reply will be received "-; 
\, i at the mobile .node 4, which will send a further registration: request If the home 
.. agent 5 continues not . to accept the registration requests, the. mobile node 4 will 
. ; 5 ultimately abandon the attempt and establish a new; tunnel /for -a "new" Care-of 

: address: without , taking advantage of ... the process of this embodiment of the _• . 
invention. This situation is inherent in mobile IP scenarios. • ; ; . 

' Figure 4 illustrates the routines followed by the home agent 5 during the ; 
above process. The routine begins at28and atstep 29 : an input is received In the 

10 > ; form of a registration request from the mobile node 24. A check is made at step 30 
whether, the registration request is valid, and if the home agent 5 does not accept 
the registration, the routine terminates at 31. If the home agent 5 does accept the 
registration request, a check is made at 32 whether the registration request was 
received through a VPN gateway such as 2, If it was not, a registration reply is 

15 r built and sent directly to the mobile node 4 over the private network 1 at step 33. If 
the registration request was received through a VPN gateway such as 2, a 
registration reply for the mobile node : 4 is built at 34. This registration reply is then 
included in a hew packet generated by the home agent 5 at 35 and which also 
contains the former Care-of address and the new Care-of address of the mobiie 

20 node 4. That packet is then sent at step 36 to the VPN gateway 2 and the routine 
terminates again at 31 . 
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" Claims I . 1 "-' ■ ' ■ : - \ 

1 A method of communication between a private network (1) and a roaming 
mobile terminal (4), said private network (1) including a home agent (5) for said 

• .. mobile terminal and : a gateway (2, 3) through which said communication 

passes and which provides secunty protection for said private network (1 ), the 
; ; ; protocols of said communication including^. bundles each ; 

" including a secunty association between said; mobile terminal; (4) and said : 
;J ; gateway (2, 3) for inbound communication and anomer security association for 
outbound communication, r 

H characterised in that, in response to a handover of communication causing an 7 
IP address (MN Co @) of said mobile terminal (4) to change to a new IP 
address (MN New Co @), said mobile terminal updates its inbound security 
association from said gateway (2, 3) so that it can receive packets sent to it 
with said new IP address (MN New Co @) as destination, said mobile terminal 
(4) sends a first signalling message with said home agent (5) as destination in 
'a secure tunnel (^EVj.to said gateway (2, 3). said first, signalling message 
• indicating, said new IP address (MN WeW'Cp ' t @V^'Wj^re Jfortriito ^said ;home . ; 
■:: agent (5); the inbound security association of said gateway (2, 3} from said 
mobile terminal (4) accepts sard first signalling message without checking its 
source address, said gateway (2, 3) forwards said first signalling message 
within said private network (1) to said home agent (5), said home agent (5) 
- checks the validity of said first signalling message and, if it is valid, updates its > 
address data and sends a second signalling message to said gateway (2 3) 
indjcating said new address (MN New Co @), and said gateway (2, 3) updates, 
its outbound security, association with said mobile terminal (4) in response to ! 

• y the new address (MN New Co @) indicated. ; , 

2. A method as claimed In claim 1, wherein communication between said mobile ■ 
node (4) and said gateway (2, 3) Is in accordance with an I Psec protocol. ; 
specification. \ - :. "y . . ■: : > -; ' : f ' 
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. -3.';. A method as claimed in, claim 2, wherein communication ' between said 1 
1 gateway (2 r 3) and said mobile terminal (4) is -in . acxxirdance with an " 
V Encapsulating Security Payjoad protocol used in tunnei mode. ; " > ;■- \. 

A. A method as claimed in any preceding claim, wherein a registration reply for ■ 
>; said mobile node (4) is included in said second signalling message: - . * Vv 

5." A mobile terminal for use in communication . by a* method as claimed in any . 
- .' preceding claim, comprising, means responsive to . a handover "of.. 
. communication causing an IP address (MN Co @) of said mobile terminal to 
- change to a new IP address (MN New Co @) for updating the inbound security ; 
:J. association of said mobile terminal (4) from said gateway (2, 3) so that it can 
: ; receive packets sent with said new IP address (MN New Co @) as destination 
and for sending a first signalling message with said home agent (5) as 
destination through a secure tunnel (20') to said gateway, said first signalling 
message indicating said new. IP address (MN New Co @) in secure form to 
said home agent (5). 

V 6. A mobile terminal for use in communication by a method as claimed in any - 
preceding claim, comprising means responsive to a handover of 
. communication causing an IP address (MN Co @) of said mobile terminal (4) 
. to change to a new IP address (MN New Co @) for updating the outbound 
security association of said mobile terminal (4) to said gateway (2, 3) so that 
said mobile terminal (4) can send packets to said gateway (2, 3) with said new 
IP address (MN New Co @) as source address. ; 

7, . A gateway for use in communication by a method as claimed In any preceding 
. claim, comprising means responsive to said first signalling message received 
in a secure tunnel (20') from said mobile terminal with said home agent (5) as 
. destination for causing said inbound security association at said gateway (2, 3) 
from said mobile terminal (4) to accept said first signalling message without 
checking its source address and for forwarding said first signalling message to 
said home agent (5), and means responsive to said second signalling /. 
message indicating said new address (MN . New. Co @) for updating said - 
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outbound security association of said gateway (2, 3) with said mobile terminal 
(4) in response to the new address (MN New Co @) indicated 

8 A home agent for use . in communication by a method as claimed in any 
preceding claim, compnsing means responsive to said first signalling message 
received from said gateway (2, 3) for sending said second signalling message 
^tp : said -gateway (2 y iyihdlcating sald. n^w. add^&;(l^. : «fow.^ 0) for said i s 

■ gateway to update its outbound security association wH^^ terminal v ' 
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